Managing Offline Data and Network Connectivity in React Native

Course: React Native Training

Topic: Managing Offline Data and Network Connectivity

Course Link: React Native Training at JustAcademy

Demo Link: Register for a Course Demo

JustAcademy Website: Visit JustAcademy

1. Introduction to Offline Data and Network Connectivity

Modern mobile applications depend on network connectivity to retrieve information, authenticate users, submit forms, load images, and communicate with backend services. However, mobile devices frequently move between Wi-Fi and cellular networks, enter areas with weak signals, or temporarily lose internet access.

React Native applications should be designed to handle these situations gracefully. Managing offline data means allowing users to access previously saved information and, when appropriate, create or update data while disconnected. Managing network connectivity means monitoring connection changes, handling failed requests, and deciding when to retry or synchronize pending operations.

A reliable offline-capable application generally combines network monitoring, local persistence, request error handling, and a synchronization strategy. React Native developers can use libraries such as NetInfo, AsyncStorage, and SQLite to build these features.

1.1 Why Offline Support Matters

• Users can continue viewing previously downloaded information without internet access.
• Forms and other user actions can be saved locally when the server is unavailable.
• Applications can recover from temporary network interruptions.
• Pending changes can be synchronized after connectivity returns.
• Clear offline indicators help users understand the current application state.
• Local caching can reduce repeated network requests and improve responsiveness.

2. Learning Objectives

After completing this topic, you should be able to:

• Understand online, offline, and intermittent connectivity.
• Monitor network changes using NetInfo.
• Display online and offline status in a React Native interface.
• Fetch and cache API data for offline access.
• Choose between AsyncStorage and SQLite for local persistence.
• Handle failed network requests and implement controlled retries.
• Queue user actions while offline.
• Synchronize pending data when the connection returns.
• Manage conflicts between local and server data.
• Test offline scenarios and build resilient mobile applications.

3. Understanding Network Connectivity

Network connectivity describes whether a device has a network connection and whether it can reach the service required by the application. A device can be connected to Wi-Fi without having access to the public internet. Similarly, a mobile network may be available but too weak or unreliable for a particular request.

3.1 Common Network States

3.2 Why Checking Connectivity Is Not Enough

Network status is an indication of connectivity, not proof that a particular API is available. DNS failures, server downtime, authentication errors, firewalls, captive portals, and request timeouts can still prevent successful communication.

Use network monitoring to decide when to attempt work, but always handle the actual result of each network request.

4. Tools and Libraries for Offline Support

Choose storage based on the application's requirements. AsyncStorage is not encrypted by default and should not be used for sensitive credentials. Use secure storage for tokens and other small secrets. SQLite is generally a better fit for larger structured datasets and more complex offline workflows.

5. Installing NetInfo

NetInfo is a cross-platform library that provides information about the device's network connection and allows applications to subscribe to changes.

5.1 Installation in an Expo Project

npx expo install @react-native-community/netinfo

5.2 Installation in a Bare React Native Project

npm install @react-native-community/netinfo
npx pod-install

Follow the library's current installation instructions for your React Native version and native project setup.

5.3 Import NetInfo

import NetInfo from '@react-native-community/netinfo';

Official documentation: NetInfo documentation for Expo and NetInfo GitHub repository.

6. Checking the Current Network Status

Use NetInfo.fetch() when you want to read the current network information once.

import NetInfo from '@react-native-community/netinfo';

async function checkNetworkStatus() {
  try {
    const state = await NetInfo.fetch();

    console.log('Connection type:', state.type);
    console.log('Connected:', state.isConnected);
    console.log('Internet reachable:', state.isInternetReachable);

    return state;
  } catch (error) {
    console.error('Unable to check network status.');
    return null;
  }
}

checkNetworkStatus();

6.1 Understanding the Returned Properties

• type: Indicates the connection type, such as Wi-Fi, cellular, or none.
• isConnected: Indicates whether a network connection is available; it may be null when unknown.
• isInternetReachable: Indicates whether internet reachability is known; it can be null when undetermined.
• details: Provides additional information depending on the connection type.

Do not interpret a null value as definitely online or definitely offline. Treat unknown connectivity as an uncertain state and allow request-level error handling to determine whether the server can be reached.

7. Listening for Network Changes

Mobile connectivity can change at any time. Use NetInfo.addEventListener() to receive updates and react when the device moves between online and offline states.

import NetInfo from '@react-native-community/netinfo';

const unsubscribe = NetInfo.addEventListener(state => {
  console.log('Connection type:', state.type);
  console.log('Connected:', state.isConnected);
  console.log('Internet reachable:', state.isInternetReachable);
});

// Call this when the listener is no longer needed.
unsubscribe();

In a React component, subscribe inside useEffect() and return the unsubscribe function from the effect. This prevents unnecessary listeners from remaining active after the component unmounts.

8. Building an Online and Offline Indicator

A network indicator informs users whether the application currently detects a network connection. It should distinguish a known offline state from an unknown state whenever possible.

import React, { useEffect, useState } from 'react';
import { View, Text } from 'react-native';
import NetInfo from '@react-native-community/netinfo';

export default function NetworkStatus() {
  const [networkState, setNetworkState] = useState(null);

  useEffect(() => {
    const unsubscribe = NetInfo.addEventListener(state => {
      setNetworkState({
        connected: state.isConnected,
        reachable: state.isInternetReachable
      });
    });

    return unsubscribe;
  }, []);

  let message = 'Checking network status...';

  if (networkState) {
    if (networkState.connected === false) {
      message = 'You are offline. Some features may be unavailable.';
    } else if (networkState.reachable === false) {
      message = 'Network connected, but internet is unreachable.';
    } else if (
      networkState.connected === true &&
      networkState.reachable === true
    ) {
      message = 'You are online.';
    } else {
      message = 'Network status is not fully known.';
    }
  }

  return (
    
      {message}
    
  );
}

8.1 Explanation

• useState() stores the latest network information.
• useEffect() subscribes to network changes after mounting.
• The event listener updates the interface when the network state changes.
• The cleanup function removes the listener.
• The component displays a useful message instead of assuming that every connection is usable.

9. Understanding Offline Data Management

Offline data management involves keeping useful information on the device so that an application can continue to operate when the server cannot be reached.

For example, a shopping application might cache product descriptions, a notes application might save drafts locally, and a field-service application might save inspection forms until connectivity returns.

9.1 Common Offline Strategies

10. Using AsyncStorage for Simple Offline Data

AsyncStorage is a persistent, asynchronous key-value storage library. It is suitable for small amounts of non-sensitive data, such as cached settings or a modest list of previously downloaded records.

10.1 Installation

npx expo install @react-native-async-storage/async-storage

10.2 Saving Data

import AsyncStorage from '@react-native-async-storage/async-storage';

async function saveCachedProducts(products) {
  try {
    await AsyncStorage.setItem(
      'cached_products',
      JSON.stringify(products)
    );
  } catch (error) {
    console.error('Unable to save cached products.');
  }
}

10.3 Reading Data

async function getCachedProducts() {
  try {
    const storedValue = await AsyncStorage.getItem('cached_products');

    if (storedValue === null) {
      return [];
    }

    return JSON.parse(storedValue);
  } catch (error) {
    console.error('Unable to read cached products.');
    return [];
  }
}

10.4 Important Considerations

• AsyncStorage stores strings, so objects and arrays must be serialized.
• Handle missing keys and invalid JSON.
• Do not store passwords, access tokens, or other secrets in AsyncStorage.
• For large datasets or complex queries, consider a local database such as SQLite.
• Cached data should have a clear refresh or expiration policy when freshness matters.

11. Using SQLite for Structured Offline Data

SQLite is a relational database that stores structured records locally on the device. It is useful when an application needs to filter, sort, update, and query a larger collection of offline records.

11.1 Installing Expo SQLite

npx expo install expo-sqlite

11.2 Creating a Local Database Table

import * as SQLite from 'expo-sqlite';

const db = await SQLite.openDatabaseAsync('offline-app.db');

await db.execAsync(`
  CREATE TABLE IF NOT EXISTS notes (
    id INTEGER PRIMARY KEY NOT NULL,
    title TEXT NOT NULL,
    body TEXT NOT NULL,
    updated_at TEXT NOT NULL,
    sync_status TEXT NOT NULL DEFAULT 'pending'
  );
`);

The table stores a note's title, body, last-update timestamp, and synchronization status. A pending status can identify local records that still need to be uploaded.

11.3 Saving a Note Locally

async function saveNoteLocally(title, body) {
  const db = await SQLite.openDatabaseAsync('offline-app.db');

  const updatedAt = new Date().toISOString();

  const result = await db.runAsync(
    `INSERT INTO notes (title, body, updated_at, sync_status)
     VALUES (?, ?, ?, ?)`,
    title,
    body,
    updatedAt,
    'pending'
  );

  return result.lastInsertRowId;
}

Parameterized SQL values help prevent SQL injection. Avoid inserting untrusted values by concatenating them directly into SQL statements.

11.4 Reading Saved Notes

async function getLocalNotes() {
  const db = await SQLite.openDatabaseAsync('offline-app.db');

  return db.getAllAsync(
    'SELECT * FROM notes ORDER BY updated_at DESC'
  );
}

Because SQLite persists data across application restarts, the application can read saved notes even when there is no network connection. This local database is only one part of offline support; synchronization still needs to be implemented.

Official reference: Expo SQLite documentation.

12. Fetching API Data with Offline Fallback

A common approach is to request fresh data from the server and save a copy locally. If the request fails, the application attempts to display the previously cached data.

import AsyncStorage from '@react-native-async-storage/async-storage';

const CACHE_KEY = 'cached_posts';
const API_URL = 'https://jsonplaceholder.typicode.com/posts';

export async function loadPosts() {
  try {
    const response = await fetch(API_URL);

    if (!response.ok) {
      throw new Error(`Request failed: ${response.status}`);
    }

    const posts = await response.json();

    await AsyncStorage.setItem(
      CACHE_KEY,
      JSON.stringify(posts)
    );

    return {
      data: posts,
      source: 'network',
      error: null
    };
  } catch (error) {
    try {
      const cachedValue = await AsyncStorage.getItem(CACHE_KEY);

      if (cachedValue !== null) {
        return {
          data: JSON.parse(cachedValue),
          source: 'cache',
          error: null
        };
      }
    } catch (cacheError) {
      console.error('Unable to read cached posts.');
    }

    return {
      data: [],
      source: 'empty',
      error: 'Unable to load posts. Please try again.'
    };
  }
}

12.1 How This Pattern Works

1. The application attempts to fetch fresh data.
2. It checks whether the HTTP response was successful.
3. It parses the returned data.
4. It saves the result to local storage.
5. If the request fails, it attempts to load the cached copy.
6. If neither the network nor the cache provides data, it returns a safe empty state and error message.

This example uses a public sample API for demonstration. Replace the endpoint with your own service. In a production implementation, consider request timeouts, cache timestamps, schema validation, pagination, and handling malformed cached data.

13. Displaying Cached Data in a React Native Screen

The following component loads posts through the offline-aware service and displays whether the data came from the network or local cache.

import React, { useEffect, useState } from 'react';
import {
  View,
  Text,
  FlatList,
  ActivityIndicator
} from 'react-native';
import { loadPosts } from './postService';

export default function PostsScreen() {
  const [posts, setPosts] = useState([]);
  const [loading, setLoading] = useState(true);
  const [source, setSource] = useState('');
  const [errorMessage, setErrorMessage] = useState('');

  useEffect(() => {
    let active = true;

    async function loadData() {
      const result = await loadPosts();

      if (active) {
        setPosts(result.data);
        setSource(result.source);
        setErrorMessage(result.error || '');
        setLoading(false);
      }
    }

    loadData();

    return () => {
      active = false;
    };
  }, []);

  if (loading) {
    return ;
  }

  return (
    
      
        {source === 'cache'
          ? 'Showing saved offline data'
          : source === 'network'
            ? 'Showing the latest downloaded data'
            : 'No data available'}
      

      {errorMessage ? {errorMessage} : null}

       String(item.id)}
        renderItem={({ item }) => (
          
            {item.title}
          
        )}
      />
    
  );
}

For a complete screen, add a retry or refresh action. If the screen should refresh when connectivity returns while it remains mounted, connect it to NetInfo or a query library that coordinates online state.

14. Handling Network Errors

Network errors may occur because of offline conditions, timeouts, server failures, invalid endpoints, or authorization problems. The application should distinguish these situations where possible and display useful messages.

14.1 Checking HTTP Response Status

async function fetchUserProfile() {
  try {
    const response = await fetch(
      'https://api.example.com/profile'
    );

    if (!response.ok) {
      if (response.status === 401) {
        throw new Error('Please sign in again.');
      }

      if (response.status >= 500) {
        throw new Error('The server is temporarily unavailable.');
      }

      throw new Error('Unable to load your profile.');
    }

    return await response.json();
  } catch (error) {
    if (error.name === 'AbortError') {
      throw error;
    }

    throw new Error(
      error.message || 'Network request failed.'
    );
  }
}

14.2 Error Categories

15. Adding Request Timeouts and Cancellation

A request should not leave the interface waiting indefinitely. Use an AbortController where supported by the React Native version and networking implementation.

async function fetchWithTimeout(url, timeoutMs = 10000) {
  const controller = new AbortController();

  const timeoutId = setTimeout(() => {
    controller.abort();
  }, timeoutMs);

  try {
    const response = await fetch(url, {
      signal: controller.signal
    });

    if (!response.ok) {
      throw new Error(`HTTP error: ${response.status}`);
    }

    return await response.json();
  } finally {
    clearTimeout(timeoutId);
  }
}

If the request is aborted because of a timeout, display a suitable message and offer retry where appropriate. When a component unmounts or the user changes screens, cancellation can prevent unnecessary requests and state updates.

Note that aborting a request does not guarantee that the server did not process it. For operations that change server data, use idempotency mechanisms or server-side safeguards where appropriate.

16. Implementing Retry Logic

Retry logic allows an application to attempt a request again after a temporary failure. It should be limited and selective to avoid excessive traffic, duplicated operations, or poor user experience.

16.1 Exponential Backoff

Exponential backoff increases the waiting period between attempts. For example, an application might wait approximately one second before the first retry, two seconds before the next, and four seconds before another. Random jitter can help prevent many clients from retrying simultaneously.

function delay(ms) {
  return new Promise(resolve => setTimeout(resolve, ms));
}

async function fetchWithRetry(url, maxAttempts = 3) {
  let lastError;

  for (let attempt = 0; attempt < maxAttempts; attempt++) {
    try {
      const response = await fetch(url);

      if (!response.ok) {
        const retryable =
          response.status === 429 ||
          response.status >= 500;

        if (!retryable) {
          throw new Error(`HTTP error: ${response.status}`);
        }

        throw new Error(`Temporary server error: ${response.status}`);
      }

      return await response.json();
    } catch (error) {
      lastError = error;

      if (attempt === maxAttempts - 1) {
        break;
      }

      const baseDelay = 1000 * (2 ** attempt);
      const jitter = Math.floor(Math.random() * 300);

      await delay(baseDelay + jitter);
    }
  }

  throw lastError;
}

This is an illustrative example. A production retry helper should distinguish non-retryable errors, connection failures, timeouts, and cancellation. It should also respect server-provided retry instructions when available. Never blindly retry payment, order creation, or other non-idempotent operations without an appropriate idempotency design.

17. Queueing Actions While Offline

Some applications need to let users perform actions even when no network is available. For example, a user might create a note, complete an inspection, or prepare a message offline.

A simple approach is to store pending operations locally and process them when connectivity returns. Each queued operation should have a stable identifier, operation type, payload, creation timestamp, and synchronization status.

17.1 Example Pending-Operation Structure

{
  "id": "operation-unique-id",
  "type": "CREATE_NOTE",
  "payload": {
    "title": "Meeting Notes",
    "body": "Discuss the project timeline."
  },
  "createdAt": "2026-10-20T10:00:00.000Z",
  "status": "pending",
  "attempts": 0
}

The example is a data structure, not a complete synchronization engine. Generate identifiers using a reliable UUID library or another collision-resistant method. Do not rely on timestamps alone as unique identifiers.

17.2 Saving a Simple Queue with AsyncStorage

import AsyncStorage from '@react-native-async-storage/async-storage';

const QUEUE_KEY = 'pending_operations';

export async function getPendingOperations() {
  try {
    const raw = await AsyncStorage.getItem(QUEUE_KEY);

    if (raw === null) {
      return [];
    }

    const operations = JSON.parse(raw);

    return Array.isArray(operations) ? operations : [];
  } catch (error) {
    console.error('Unable to read pending operations.');
    return [];
  }
}

export async function enqueueOperation(operation) {
  const operations = await getPendingOperations();

  operations.push({
    ...operation,
    status: 'pending',
    attempts: 0
  });

  await AsyncStorage.setItem(
    QUEUE_KEY,
    JSON.stringify(operations)
  );
}

This small example is appropriate only for simple cases. Concurrent writes can overwrite one another, and a failed read may be indistinguishable from an empty queue. For reliable applications, use a database-backed queue, validated records, serialized queue updates, and explicit failure reporting.

18. Synchronizing Pending Data When Connectivity Returns

When a connection becomes available, the application can attempt to send pending operations to the server. A basic synchronization process reads pending items, submits them, and marks successfully processed operations as complete.

18.1 Basic Synchronization Flow

1. Detect that network connectivity may be available.
2. Verify that the backend is reachable by making a real request.
3. Load pending operations from local persistence.
4. Process each operation using the appropriate API endpoint.
5. Confirm that the server accepted the operation.
6. Mark successful operations as synchronized or remove them from the queue.
7. Keep failed operations for a later retry when appropriate.
8. Update the interface to show synchronization status.

18.2 Example Synchronization Function

async function syncPendingNotes(notes) {
  const remaining = [];

  for (const note of notes) {
    try {
      const response = await fetch(
        'https://api.example.com/notes',
        {
          method: 'POST',
          headers: {
            'Content-Type': 'application/json'
          },
          body: JSON.stringify({
            id: note.id,
            title: note.title,
            body: note.body
          })
        }
      );

      if (!response.ok) {
        throw new Error('The server did not accept the note.');
      }
    } catch (error) {
      remaining.push(note);
    }
  }

  return {
    syncedCount: notes.length - remaining.length,
    remaining
  };
}

This function demonstrates the core idea, but it does not persist the queue itself or distinguish permanent failures from temporary ones. In a production system, update each record's status transactionally, retain failure details, use bounded retries, and ensure the server can safely recognize duplicate operations.

19. Avoiding Duplicate Operations During Synchronization

A common problem occurs when a request reaches the server but the response is lost. The application may retry the request without knowing whether the server already processed it. This can create duplicate records or repeated actions.

Useful protections include:

• Assign each operation a stable unique identifier.
• Use server-supported idempotency keys for operations that support them.
• Make API endpoints idempotent where practical.
• Persist synchronization status so the app can recover after restarting.
• Do not delete a pending operation before receiving a reliable success response.
• Use transactions when changing local records and their sync statuses.

20. Handling Data Conflicts

Data conflicts happen when the same record changes in more than one place before synchronization. For example, a note might be edited offline on one device while another device changes the same note on the server.

20.1 Common Conflict Resolution Strategies

Do not automatically overwrite server data without understanding the application's business rules. Timestamps alone may not be sufficient to determine which version is correct, especially when device clocks differ.

21. Building an Offline-First Application

An offline-first application treats local data as the primary source for the interface rather than waiting for the network on every screen. It can display saved data immediately, record changes locally, and synchronize them with the backend as appropriate.

21.1 Recommended Architecture

1. UI layer: Displays data, loading states, offline indicators, and synchronization status.
2. Repository layer: Decides whether data should be read from the local database or remote API.
3. Local storage layer: Persists records and pending operations.
4. Network layer: Sends requests and processes responses.
5. Synchronization layer: Uploads pending changes, refreshes remote data, and resolves conflicts.
6. Backend layer: Validates requests, enforces authorization, and stores the authoritative server data.

21.2 Example Offline-First Flow

User opens the application
        |
        v
Read saved data from local storage
        |
        v
Display available information immediately
        |
        v
Check network status and request server data
        |
        +---- Request succeeds ----> Update local data
        |                                |
        |                                v
        |                         Refresh the UI
        |
        +---- Request fails ------> Keep cached data
                                         |
                                         v
                                  Show offline message
                                         |
                                         v
                              Retry when appropriate

22. Using a Query Library for Network-Aware Data

Libraries such as TanStack Query can simplify remote-data caching, request lifecycle management, and refetching. When using such a library, connect its online manager to NetInfo so queries can respond appropriately to network changes.

22.1 Example Integration

import { onlineManager } from '@tanstack/react-query';
import NetInfo from '@react-native-community/netinfo';

onlineManager.setEventListener(setOnline => {
  return NetInfo.addEventListener(state => {
    setOnline(
      state.isConnected === true &&
      state.isInternetReachable !== false
    );
  });
});

This integration treats a disconnected network or a known unreachable internet state as offline. An unknown reachability value is not automatically treated as a confirmed failure. You should still handle individual request errors because network status cannot guarantee API availability.

TanStack Query's cache is useful for remote server state, but it is not automatically a durable offline database for every application requirement. Configure persistence separately if needed, and use a database-backed approach for complex offline editing and synchronization.

23. App Lifecycle and Network Recovery

Connectivity may return while the app is in the background or after it has been reopened. Do not assume a network listener alone will complete every synchronization task under all mobile operating-system conditions.

• Recheck connectivity when the application returns to the foreground.
• Run synchronization when the app is active and conditions allow it.
• Persist pending operations so they survive application restarts.
• Use platform-supported background-task facilities when background synchronization is required.
• Do not promise immediate background synchronization; operating systems may delay or restrict it.
• Ensure that foreground synchronization can recover unfinished background work.

24. Security Considerations for Offline Data

Offline support increases the amount of data stored on the device. Developers must consider what happens if the device is lost, shared, rooted, jailbroken, or accessed by an unauthorized person.

• Store only the data required for offline functionality.
• Never save passwords or access tokens in ordinary AsyncStorage.
• Use secure storage for small sensitive credentials.
• Consider database encryption when offline records contain sensitive information and the threat model requires it.
• Use HTTPS for network communication.
• Validate and authorize every important operation on the server.
• Avoid writing private information to debug logs or crash reports.
• Apply appropriate retention and deletion policies to cached records.
• Consider logout behavior on shared devices and remove sensitive local data when appropriate.

25. Testing Offline Functionality

Offline behavior must be tested deliberately rather than assumed to work because the application runs successfully on a stable Wi-Fi connection.

25.1 Test Scenarios

26. Common Problems and Troubleshooting

27. Best Practices for Offline and Connectivity Management

1. Design for unreliable networks: Assume that requests can fail even when the device appears connected.
2. Show cached data quickly: Avoid blocking the entire interface while waiting for the server.
3. Keep network and storage logic separate: Use service or repository modules rather than placing every operation directly inside UI components.
4. Persist important user changes: Do not rely only on in-memory state for actions that must survive a restart.
5. Use appropriate storage: AsyncStorage suits small non-sensitive values; SQLite suits structured local data.
6. Use bounded retries: Prevent endless retry loops and excessive battery or data consumption.
7. Design for duplicate requests: Use idempotency and stable operation identifiers when necessary.
8. Define conflict rules: Decide how local edits interact with remote changes before release.
9. Handle unknown states: Do not interpret missing connectivity information as a guaranteed online or offline state.
10. Keep users informed: Show whether information is cached, pending, synchronized, or failed.
11. Protect local data: Treat offline records as data that may remain on the device after the session ends.
12. Test real conditions: Test airplane mode, weak connections, server errors, app restarts, and concurrent changes.

28. Practical Project: Offline Notes Application

Create a React Native notes application that allows users to read and create notes without internet access and synchronizes pending notes with a backend when possible.

28.1 Project Requirements

• Display the current network status.
• Load existing notes from local storage when the screen opens.
• Save new notes locally even when offline.
• Mark new notes as pending synchronization.
• Detect connectivity changes with NetInfo.
• Attempt synchronization when connectivity returns.
• Mark notes as synchronized only after a successful server response.
• Keep failed operations in the queue.
• Show loading, empty, offline, and error states.
• Prevent duplicate note creation during retries.

28.2 Suggested Project Structure

src/
  components/
    NetworkStatus.js
    NoteItem.js
    SyncStatus.js
  services/
    apiService.js
    connectivityService.js
    syncService.js
  storage/
    noteRepository.js
    pendingQueue.js
  screens/
    NotesScreen.js
  App.js

28.3 Implementation Steps

1. Install NetInfo and your chosen local storage library.
2. Create the local database or storage utilities.
3. Build a screen that displays locally saved notes.
4. Implement note creation and save each note locally.
5. Record the synchronization status of each note.
6. Create an API service that uploads pending notes.
7. Listen for connectivity changes and trigger eligible synchronization work.
8. Add duplicate prevention, retry handling, and conflict rules.
9. Test with no internet, weak connectivity, server errors, and app restarts.

28.4 Expected Result

• Users can open and read previously saved notes while offline.
• New notes remain available after the application restarts.
• Pending notes are not lost when a request fails.
• The app shows which notes still need synchronization.
• When connectivity returns, eligible notes are uploaded without unintended duplication.
• Errors are communicated clearly without exposing internal technical details or sensitive information.

29. Practice Exercises

1. Install NetInfo and create a component that displays the current connection state.
2. Subscribe to connectivity changes and confirm that the listener is cleaned up correctly.
3. Fetch a list of products from an API and save the result locally.
4. Disconnect from the internet and confirm that cached products remain visible.
5. Add a refresh button and show loading and error states.
6. Save a new note locally when offline.
7. Implement a pending-operation queue with unique operation identifiers.
8. Upload pending notes after connectivity returns.
9. Simulate a server error and verify that unsuccessful operations remain pending.
10. Document and implement a conflict-resolution policy.
11. Compare AsyncStorage and SQLite for the project's data requirements.
12. Test the application after closing and reopening it while offline.

30. Interview Questions and Answers

Q1. What is offline data management in React Native?

Answer: It is the practice of storing useful data locally and allowing supported application operations to continue when a network or backend service is unavailable.

Q2. What is NetInfo?

Answer: NetInfo is a cross-platform library that provides network connection information and allows applications to listen for connectivity changes.

Q3. How do you check the current network status?

Answer: Use NetInfo.fetch() to retrieve the current connection information asynchronously.

Q4. How do you listen for network changes?

Answer: Use NetInfo.addEventListener() and unsubscribe when the listener is no longer required.

Q5. Does a Wi-Fi connection guarantee internet access?

Answer: No. The Wi-Fi network may lack internet access, or the server, DNS, or route may be unavailable. Always handle actual request failures.

Q6. What is offline caching?

Answer: Offline caching saves previously retrieved information locally so the application can display it without making another network request.

Q7. When should you use AsyncStorage?

Answer: AsyncStorage is suitable for small amounts of non-sensitive persistent data, such as preferences and simple cached values.

Q8. When should you use SQLite?

Answer: SQLite is appropriate for structured local datasets that require queries, filtering, sorting, updates, and more advanced offline behavior.

Q9. What is an offline-first application?

Answer: It prioritizes local data for the user interface, allowing the user to access and modify supported information locally while synchronization with the backend happens separately.

Q10. What is a synchronization queue?

Answer: It is a persistent collection of operations waiting to be processed by a remote service when the required connectivity and authentication conditions are available.

Q11. What is exponential backoff?

Answer: It is a retry strategy that increases the delay between attempts, reducing excessive traffic during temporary failures.

Q12. What is a data conflict?

Answer: A conflict occurs when local and remote versions of the same record have changed independently. It requires an explicit resolution strategy.

Q13. How can duplicate operations be prevented?

Answer: Use stable operation identifiers, idempotent API design, and server-supported idempotency keys when appropriate.

Q14. Why should pending operations be persisted?

Answer: Persistence allows pending work to survive application restarts, device interruptions, and temporary connectivity failures.

Q15. Why is a network listener not sufficient for reliable synchronization?

Answer: A network listener reports connectivity changes but cannot guarantee server availability, successful authentication, or successful completion of an API operation.

Q16. How do you test an offline-capable application?

Answer: Test airplane mode, weak connections, server errors, request timeouts, app restarts, pending queues, duplicate requests, and conflicts between local and remote data.

31. Quick Revision Checklist

• NetInfo provides network status and change notifications.
• Network connectivity does not guarantee that the backend is reachable.
• AsyncStorage can cache small amounts of non-sensitive data.
• SQLite is suitable for structured local datasets and complex offline workflows.
• Load saved data when immediate offline access is important.
• Handle request errors, HTTP status codes, and timeouts.
• Retry only eligible operations and use bounded backoff.
• Persist pending operations and track their synchronization status.
• Prevent duplicate operations using stable identifiers and server-side safeguards.
• Define rules for resolving local and server data conflicts.
• Never store authentication secrets in ordinary unencrypted storage.
• Test offline behavior and synchronization across application restarts.

32. Conclusion

Managing offline data and network connectivity is essential for building reliable React Native applications. NetInfo helps monitor network changes, while AsyncStorage and SQLite provide different options for persisting data locally. Together with robust API handling, a durable synchronization queue, and clear conflict-resolution rules, these tools help applications remain useful when connectivity is unreliable.

The best solution depends on the application. A simple app may need only cached data and an offline indicator, while a complex application may require a local database, queued operations, retry policies, and a complete synchronization architecture. In every case, prioritize data integrity, security, predictable recovery, and a clear user experience.

33. Additional Learning Resources

• React Native Training Course – JustAcademy
• Register for a Course Demo – JustAcademy
• Official JustAcademy Website
• NetInfo Documentation
• NetInfo GitHub Repository
• Expo SQLite Documentation
• Expo Guide to Storing Data
• Expo Local-First Architecture Guide
• React Native Security Guide